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0 A method and system for dynamically generating object connections is provided, in a preferred embodi- 
ment, a connection can be generated between a source object and a sink object using a connection point object. 
A source object has connection point objects where each connection point object corresponds to a particular 
interface. A sink object implements one or more notification interfaces for connecting to a source object. A 
connection point object of a source object can connect to multiple notification interfaces, which belong to one or 
more sink objects. A connection point object keeps track of pointers to the notification interfaces to which it has 
been connected. In order to generate a connection, a sink object requests from a source object a connection 
point object corresponding to a particular interface. The source object determines whether it supports such a 
connection point object, and if so returns a pointer to the connection point interface of the determined 
connection point object. The sink object then requests to be connected to the connection point object using the 
returned connection point interface pointer and passes a reference to a notification interface of the sink object 
corresponding to the particular interface. The connection point object then stores the reference to the notification 
interface of the sink object, creating a connection between the sink object and the source object. At some later 
time, the source object can utilize the connection to notify the sink object through the connected notification 
interfaces. 
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Technical Field if iJ 

soe^LT^^T^T 9 f enera " y t0 3 C ° mPU,er SyS,6m ' 0r C ° nnectin 9 and ' •*« 

specifically, to a method and system for generating object connections for notification purposes. 

Background of the Invention 



occu? For TZZ 13 Creat6d that needS ,0 communicate wi > h other software when certain events 
occur. For example, ,n a computer endowing system, when a user selects a window on the display the 

been selected In pnor systems, the software needing notification of certain events registers the events for 
which . .ants t0 be notified with the software that raises the events. In some prior systems, as part of the 

oS The? hrr needin9 n ° ,ifiCati0n re9iS,erS 3 noti,ication func,ion b V whichTca be 

» fun ton il calied Thi > t T" " ™* ** *" the re 9 istered Nation 

/5 tunction is called. This is known in the prior art as a callback mechanism 

An overview of well-known object-oriented programming techniques is provided, since the present 
Ta^mL Z be ' 0W ° biect -° riented ««W common characteristics of obj c -or Sted 
refer r h ?h H 9 9 ?^ "* SUPPOrt ^ enca P sulation and da * type inheritance. Data encapsulation 
,a otheTdata typts ' ^ "* ^ ' nheri,anC6 ^ * the abi " ty '° deClare a data ^ in 'erms of 

a uiV^finl^ lan9 A a9 , 8 ' ob i ec, -° riented ^hniques are supported through the use of classes. A class is 
a user-defined type. A class declaration describes the data members and function members of the class 

aRCLE mP Wi " 9 deC ' arati0n de ' ineS ^ membefS 3nd 3 funCti0n member <* a class nam ed 

25 

class CIRCLE 
{ public: 

30 int x, y; 

int radius; 
void drawQ; 



35 



Sl» 1 X T " ^ C6nter '° Cati0n ° f 3 Cirde and variable radius s P ecifies ,h * ^dius of the circle 

func ,on th a t ^ T 6rred t0 33 d3ta m6mberS ° f ' he Cl3SS CIRCLE The d ™ ^ a user -de Led 

func , on that draws the c.rcle of the specified radius at the specified location. The function draw is referred 

Th P d V °k memb6r ° f C ' aSS C,RCLE A fUnC,i0n member is also re ^* d •«» as a method o a class 

insLce a 0 T,;?r ss an A d ,Ur, f 0n m ! mberS ° f 3 ^ ^ b ° Und ^ in ,hat the *«*n operated o an 
instance of the class. An instance of a class is also called an object of the class 

CIRCLE 8 °' C+ + ' f °" 0Win9 S,atement dedareS the objec,s a and b ,0 b * o' 'yp« class 

45 CIRCLE a, b; 

^TfT C8US ! S al ' 0CatiOn ° f mem ° ry f0r the objects a and b - The Allowing statements assign 
data to the data members of objects a and b. owwmwu* assign 

a.x = 2; 

a. y =2; 

so a.radius = 1; 

b. x = 4; 
b.y =5; 
b.radius = 2; 

The following statements are used to draw the circles defined by objects a and b 
55 a.drawQ; 
b.draw(); 

base A da e il d fT * ' ^V** inh6ri,S ^ cha ^teris,i CS -data members and function members-of its 
base classes. For example, the following derived Cass CIRCLE FILL inherits the characteristics of the 



BNSOOOD: <BP 0660231 A2> 



EP 0 660 231 A2 



jo 



base class CIRCLE. 



class CIRCLE_FILL : CIRCLE 
{ public: 

int pattern; 
void fillO; 

}; 



This declaration specifies that class CIRCLE FILL includes all the data and function members that are in 

class CIRCLE in addition to those data and function members introduced in the declaration of class 

/5 ClRCLE__FILL, that is, data member pattern and function member fill. In this example, class CIRCLE FILL 

has data members x, y. radius, and pattern and function members draw and fill. Class CIRCLE FILL is" said 

to "inherit" the characteristics of class CIRCLE. A class that inherits the characteristics of another class is a 

derived class (e.g., CIRCLE FILL). A class that does not inherit the characteristics of another class is a 

primary (root) class (e.g.. CIRCLE). A class whose characteristics are inherited by another class is a base 

20 class (e.g., CIRCLE is a base class of CIRCLE FILL). A derived class may inherit the characteristics of 

several classes, that is. a derived class may have several base classes. This is referred to as multiple 
inheritance. 

A derived class may specify that a base class is to be inherited virtually. Virtual inheritance of a base 
class means that only one instance of the virtual base class exists in the derived class. For example, the 
25 following is an example of a derived class with two nonvirtual base classes. 

class CIRCLE_1 : CIRCLE {...}; 

class CIRCLE_2 : CIRCLE {...}; 

class PATTERN : CIRCLE_1. CIRCLE_2{ ..}; 
In this declaration class PATTERN inherits class CIRCLE twice nonvirtually through classes CIRCLE_1 and 
30 CIRCLE_2. There are two instances of class CIRCLE in class PATTERN. 

The following is an example of a derived class with two virtual base classes. 

class CIRCLE_1 : virtual CIRCLE {...}; 

class CIRCLE__2 : virtual CIRCLE {...}; 

class PATTERN: CIRCLE 1, CIRCLE_2{...}; 

35 The derived class PATTERN inherits class CIRCLE twice virtually through classes CIRCLE_1 and 
CIRCLE_2. Since the class CIRCLE is virtually inherited twice, there is only one object of class CIRCLE in 
the derived class PATTERN. One skilled in the art would appreciate virtual inheritance can be very useful 
when the class derivation is more complex. 

A class may also specify whether its function members are virtual. Declaring that a function member is 
40 virtual means that the function can be overridden by a function of the same name and type in a derived 
class. In the following example, the function draw is declared to be virtual in classes CIRCLE and 
CIRCLE FILL 
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class CIRCLE 
{ public: 

int x. y; 

int radius; 

virtual void draw(); 

}: 

class CIRCLE_FILL : CIRCLE 
{ public: 

int partem; 
virtual void draw(); 

}; 



If a virtual function is declared without providing an implementation, then it is referred to as a pure virtual 
function. A pure virtual function is a virtual function declared with the pure specifier, "= 0" If a class 
specifies a pure virtual function, then any derived class needs to specify an implementation for that function 
member before that function member may be invoked. 

in order to access objects, the C + + language provides a pointer data type. A pointer holds values that 
are addresses of objects in memory. Through a pointer, an object can be referenced. The following 
statement declares variable c_ptr to be a pointer on an object of type class CIRCLE and sets variable 
c_ptr to hold the address of object c. 
CIRCLE *c_ptr; 
30 c_ptr = &c; 

Continuing with the example, the following statement declares object a to be of type class CIRCLE and 
object b to be of type class CIRCLE FILL. 

CIRCLE a; 

CIRCLE FILL b; 

35 The following statement refers to the function draw as defined in class CIRCLE. 

a. draw(); 

Whereas, the following statement refers to the function draw defined in class CIRCLE FILL 

b. drawQ; — 

Moreover, the following statements type cast object b to an object of type class CIRCLE and invoke the 

40 function draw that is defined in class CIRCLE FILL. 

CIRCLE 'c_ptr; 
c_ptr = &b: 

c_ptr->draw(); // CIRCLE RLL::draw() 

Thus, the virtual function that is called is function CIRCLE FILL::draw. 

Figure 1 is a block diagram illustrating typical data structures used to represent an object. An object is 
composed of instance data (data members) and member functions, which implement the behavior of the 
object. The data structures used to represent an object comprise instance data structure 101 virtual 
funct.cn table 102, and the function members 103, 104, 105. The instance data structure 101 contains a 
pointer to the virtual function table 102 and contains data members. The virtual function table 102 contains 
an entry for each virtual function member defined for the object. Each entry contains a reference to the 
code that implements the corresponding function member. The layout of this sample object conforms to the 
model defmed in U.S. Patent Application Serial No. 07/682,537, entitled "A Method for Implementing Virtual 
Functions and Virtual Bases in a Compiler for an Object Oriented Programming Language," which is hereby 
incorporated by reference. In the following, an object will be described as an instance of a class as defined 
by the C+ + programming language. One skilled in the art would appreciate that objects can be defined 
using other programming languages. 

An advantage of using object-oriented techniques is that these techniques can be used to facilitate the 
sharing of objects. In particular, object-oriented techniques facilitate the creation of compound documents. A 
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compound document is a document that contains objects generated by various computer programs. 
(Typically, only the data members of the object and the class type are stored in a compound document.) 
For example, a word processing document that contains a spreadsheet object generated by a spreadsheet 
program is a compound document. A word processing program allows a user to embed a spreadsheet 

5 object (e.g., a cell) within a word processing document. To allow this embedding, the word processing 
program is compiled using the class definition of the object to be embedded to access function members of 
the embedded object. Thus, the word processing program would need to be compiled using the class 
definition of each class of objects that can be embedded in a word processing document. To embed an 
object of a new class into a word processing document, the word processing program would need to be 

;o recompiled with the new class definition. Thus, only objects of classes selected by the developer of the 
word processing program can be embedded. Furthermore, new classes can only be supported with a new 
release of the word processing program. 

To allow objects of an arbitrary class to be embedded into compound documents, interfaces are 
defined through which an object can be accessed without the need for the word processing program to 

zs have access to the class definitions at compile time. An abstract class is a class in which there is at least 
one virtual function member with no implementation (a pure virtual function member). An interface is an 
abstract class with no data members and whose virtual functions are all pure. Thus, an interlace provides a 
protocol for two programs to communicate. Interfaces are typically used for derivation: a program 
implements classes that provide implementations for the interfaces the classes are derived from. Thereafter, 

20 objects are created as instances of these derived classes. 

The following class definition is an example definition of an interface. In this example, for simplicity of 
explanation, rather than allowing any class of object to be embedded in its documents, a word processing 
program allows spreadsheet objects to be embedded. Any spreadsheet object that provides this interface 
can be embedded, regardless of how the object is implemented. Moreover, any spreadsheet object, 

25 whether implemented before or after the word processing program is compiled, can be embedded. 

ISpreadSheet 
virtual void File() = 0; 
virtual void Edit() = 0; 
virtual void Formula() = 0; 
virtual void FormatO = 0; 
virtual void GetCell (string RC, cell *pCell) = 0; 
virtual void Data() = 0; 

40 

The developer of a spreadsheet program would need to provide an implementation of the interface to allow 
the spreadsheet objects to be embedded in a word processing document. 

When the word processing program embeds a spreadsheet object, the program needs access to the 
code that implements the interface for the spreadsheet object. To access the class code, each implementa- 

45 tion is given a unique class identifier. For example, code implementing a spreadsheet object developed by 
Microsoft Corporation may have a class identifier of "MSSpreadsheet," while code implementing a 
spreadsheet object developed by another corporation may have a class identifier of "LTSSpreadsheet." A 
persistent registry in each computer system is maintained that maps each class identifier to the code that 
implements the class. Typically, when a spreadsheet program is installed on a computer system, the 

so persistent registry is updated to reflect the availability of that class of spreadsheet objects. So long as a 
spreadsheet developer implements each function member defined by the interface and the persistent 
registry is maintained, the word processing program can embed instances of the developer's spreadsheet 
objects into a word processing document. The word processing program accesses the function members of 
the embedded spreadsheet objects without regard to who has implemented them or how they have been 

55 implemented. 

Various spreadsheet developers may wish, however, to implement only certain function members. For 
example, a spreadsheet developer may not want to implement database support, but may want to support 
all other function members. To allow a spreadsheet developer to support only some of the function 

5 
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members while still allowing the objects to be embedded, multiple interfaces lor spreadsheet objects are 
defined. For example, the interfaces .Database and .Basic may be defined for a spreadsheet object Z 



class IBasic 

{ virtual void FileO = 0; 
virtual void Edit() = 0; 
virtual void Formula() = 0; 
virtual void Format() = 0; 
virtual void GetCell (string RC, cell *pCell) = O 

} 

class IDatabase 

{ virtual void DataQ = 0; 

} 

Each spreadsheet developer would implement the IBasic interface and, optionally, the IDatabase interface 
.mh^ 6 ' J* 7° rd „? rocessin 9 P r °9ram would need to determine whether a spreadsheet object to be 
embedded- supports the IDatabase interface. To make this determination, another interface is defined Jhat 
ZUTT B t ° b,e rl imp,ements > with a fun «ion member that indicates which interfaces are imp e 
mented for the object. Th,s interface is named .Unknown (and referred to as the unknown interface or "he 
object management interface) and is defined as follows. 

class [Unknown 

{ virtual HRESULT Querylnterface (REFIID iid, void **ppv) = 0; 
virtual ULONG AddRef() = 0; 
virtual ULONG Release () = 0; 

} 

; nt f rface H def f S ,he funCti0n member (method > Querylnterface. The method Querylnterface 
he ?mS m « 2 , TT (e ' 9 - " IDa,abase ") if1 P™-*" iid (of type REFIID) and returns a pointers 

oov T^'tV f nt ' f,ed imerfaCe f0f the ° bjeCt f0r which the method is inv ^ed in parameter 
ppv. I the object does not support the interface, then the method returns a false. The type HRESULT 
md.cates a predefined status, and the type ULONG indicates an unsigned long integer 
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Code Table l 

H RESULT XX:;Querylmerface{REFIID iid, void **ppv) 
{ ret = TRUE; 

switch (iid) { 
case HDJBasic: 

*ppv = *plBasic; 
break; 
case IID_rDatabase: 

*ppv = *p[Database; 
break; 
case HDJUnknown: 
*ppv = this; 
break; 

default: 

ret = FALSE; 

} 

if (ret = TRUE) {AddRefO;}; 
return ret; 

} ■ 



Code Table 1 contains pseudocode for C + + source code for a typical implementation of the method 
25 Guerylnterface for class XX, which inherits the class (Unknown. If the spreadsheet object supports the 
IDatabase interface, then the method Querylnterface includes the appropriate case label within the switch 
statement. The variables pIBasic and pIDatabase point to a pointer to the virtual function tables of the IBasic 
and IDatabase interfaces, respectively. The method Querylnterface invokes to method AddRef (described 
below) to increment a reference count for the object of class XX when a pointer to an interface is returned. 

30 



void XX::AddRef{) {refcount-f-r:} 
35 void XX::Reiease() {if («refcount=0) delete this;} 



The interface lUnknown also defines the methods AddRef and Release, which are used to implement 
reference counting. Whenever a new reference to an interface is created, the method AddRef is invoked to 
40 increment a reference count of the object. Whenever a reference is no longer needed, the method Release 
is invoked to decrement the reference count of the object and, when the reference count goes to zero, to 
deallocate the object. Code Table 2 contains pseudocode for C + + source code for a typical implementa- 
tion of the methods AddRef and Release for class XX, which inherits the class lUnknown. 

The IDatabase interface and IBasic interface inherit the lUnknown interface. The following definitions 
45 illustrate the use of the lUnknown interface. 
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class IDatabase : public IUnknown 
{ public: 

virtual void Data() = 0; 
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class IBasic : public IUnknown 
{ public; 

virtual void File() = 0; 

virtual void Edit() = 0; 

virtual void Formula() = 0; 

virtual void Format() = 0; 

virtual void GetCell (string RC, cell *pCell) = 0; 

} 



25 



The following pseudocode illustrates how a word processing program uses an IUnknown interface to 
determine whether a spreadsheet object supports the IDatabase interface, 
if (pSpreadsheet->Querylnterface("IDatabase", &plDatabase)) 
// IDatabase supported 
else 

// IDatabase not supported 

The pointer pSpreadsheet is a pointer to an instance of a spreadsheet class. As discussed above the 
30 spreadsheet object may include some interfaces and not others. If the object supports the IDatabase 
interface, the method Querylnterface sets the pointer pIDatabase to point to a IDatabase data structure and 
returns true as its value. 

. Figure 2 is a symbolic ^presentation of a spreadsheet object. In the following, an object data structure 
is represented by the shape 201 labeled with the interfaces through which the object may be accessed. 



35 



40 



Summary of the Invention 

object connecticS °' PreS6nt inVent '° n '° Pr ° Vid6 * $y$tem f ° f d y namicallv generating 

It is another object of the present invention to provide a method and system for connecting an arbitrary 
interface for subsequent notification purposes. 

It is another object of the present invention to provide multiple points of connection connecting with 
multiple notification routines. a 

It is another object of the present invention to provide a mechanism for determining whether an object 
45 has a particular interface for connecting. 

mn ' S f 0(he ; °b|ect of the present invention to provide a method and system for invoking previously 
connected notification routines without any knowledge of what tasks they perform 

a JlLl a0Ct T 0b i eCt °L thS Pr6Sent inVen,i0n ,0 Pr0vide a method and s V stem for event handling using 
application independent object interfaces. a 

™ ese and other objects, which will become apparent as the invention is more fully described below 

ZfeZTTJLZTT™* meth ° d SyStem ' 0r d * namical| y generating object connections. In a 
preferred embodiment, the present invention comprises a source object and a sink object. The source 

t ™ a ' nS ,° ne Z T e COnnection P° int ob i ect * e^h of which contains a connection point interface 

lh ^ rn t S k JeCtS - Ch Sink ° bi6Ct haS 3 n ° ti,iCati0n interface for communicating to the sink 
object To establish a connection, the source object determines which connection point object to use for a 

T^L'TT™ USinQ thiS de,ermined action point object, the sink object requests to be 

connected o the source object passing an indication of a notification interface to be used for further 
communication. The source object then stores the indicated notification interface in a data structure 
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managed by the connection point object. Later, the source object determines what notification interfaces 
have been stored in a particular connection point object and invokes a particular method of each stored 
notification interface to notify each sink object that has connected a notification interface. Such notification 
typically occurs in response to an event, for example, movement from a user input device. 

s 

Brief Description of the Drawings 

Figure 1 is a block diagram illustrating typical data structures used to represent an object. 
Figure 2 is a symbolic representation of a spreadsheet object. 
10 Figure 3 is a block diagram of a preferred connection mechanism architecture. 

Figure 4 is a block diagram of a connection between a source object, a delegate object and a sink 
object. 

Figure 5 is a block diagram of a visual programming environment display used to create an open file 
dialog box for an application program. 
f5 Figure 6 is a block diagram of object connections and data structures after connecting the objects 
shown in Figure 5 using the present invention. 

Figure 7 is a flow diagram of a function SetUpConnection for connecting a specified sink object to a 
specified source object for a specified notification interface. 

Figure 8 is a flow diagram for the method FindConnectionPoint of the IConnectionPointContainer 
20 interface. 

Figure 9 is a flow diagram of a method that uses an established connection between a source object 
and a sink object. 

Figure 10 is a flow diagram of a function defined by a sink object to disconnect a specified notification 
interface. 

25 

Detailed Description of the Invention 

The present invention provides a method and system for generating object connections between source 
objects and sink objects. These connections can be used to support multiple types of event handling 

30 mechanisms for objects; the invention provides an underlying connection mechanism architecture for object 
communication. A source object refers to an object that raises or recognizes an event, and a sink object 
refers to an object that handles the event. A connection between a source and sink object may be directly 
initiated by either object or by a third object, referred to as an initiator object. In a typical event handling 
environment, the source object raises or recognizes an event and notifies the sink object or initiator object 

35 by invoking a notification method. If the notification method belongs to the initiator object, then the initiator 
object is responsible for invoking an appropriate method of the sink object to handle the event. 

In a preferred embodiment, the methods and systems of the present invention are implemented on a 
computer system comprising a central processing unit, memory, and input/output devices. In a preferred 
embodiment of the present invention, a source object comprises connection point objects and a connection 

<*o point container object for managing the connection point objects. Preferably, the connection point container 
object is implemented as part of the source object and the connection point objects are implemented as 
subobjects of the source object. The subobjects isolate the application independent behavior of the present 
invention. The connection point container object provides an interface comprising a method that can 
enumerate the contained connection point objects and a method that can find a connection point object 

45 corresponding to a particular interface identifier ("ID"). A connection point object is associated with a certain 
type of interface (identified by an interface ID) through which it notifies sink objects to which it is connected. 
A connection point object preferably provides an interface that comprises methods for connecting a 
notification interface, for disconnecting a previously connected notification interface, and for enumerating the 
connected notification interfaces. A connection point object preferably can optionally store references to 

so multiple notification interfaces (belonging to one or more sink objects). A connected notification interface 
acts as an event set. That is, by virtue of the definition of an interface, each object supporting a 
documented interface must provide a certain set of methods. Thus, when a sink object connects a 
notification interface, the source object automatically knows what methods are supported by the notification 
interface. From this perspective, the methods supported loosely correspond to events, and the entire 

55 notification interface loosely corresponds to a set of events. 

Once connected, the source object can use the connection point objects in a variety of manners. In 
typical operation, the source object, upon receiving an event notification, consults the connection point 
object(s) that is (are) associated with the interface ID corresponding to the received event to obtain the 

9 
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connected no ,f,cat,on .nterfaces. The source object then forwards the event notification to each connected 
notification interface by coking a predetermined method of the notification interface. In this manner 
several s.nk objects can be notified upon the occurrence of a single event. 

Figure 3 is a block diagram of a preferred connection mechanism architecture. This figure shows a 
source .object 301 connected to two sink objects 302 and 303 through two connection point objects 305 and 
306. The source object 301 implements a connection point container object 304 for managing the 

^SKr" ° - ?? 3 °L- 306 ' C ° nneCti0n P ° mt C ° ntainer ° bjeCt 304 imp,emen,s an 
!h h ,T 30 f ° f enumeratin 9 and findin 9 connection point objects. The connection point 

, SI ? p 3 t r aCC8SSed bV the connection PO^t container object 304 through their respective 
> 'Connect.onPo.nt .nterfaces. 308 and 309. The connection point objects 305 and 306 a're connected to the 
sink objects 302 and 303 through their respective notification interfaces 310 and 311. The source object 301 
notifies the s.nk objects 302 and 303 of the occurrence of an event by locating the IConnectionPoint 
interface corresponding to the event and invoking a method of the notification interface of the sink object 
nh . * S ™ ent| oned above, a connection between a source and sink object can be initiated by an initiator 
object. The .nrtiator object can either connect a notification interface of the sink object to the source object 
ZzZ^ZVJ n0,i ;| ca,i0 " in ' erface ° f own "delegate" object. A delegate object is simply an object 

cur e and I * T "* ^ "™* The de ' e9ate ° bieC « is '^parent to both the 

source ^and s.nk object because ,t prov.des an implementation for the interface corresponding to the 
connection po.nt object, just as the sink object provides. The delegate object is responsible for forwardng 

mechan l ? h ^° !" *" mmer ' th6 dele9at8 0b ' ect Can * ^ « a security 

mechan.sm, dec.d.ng whether or not to forward an event notification based upon the comparative authoriza- 
tion privileges of the source and sink objects. M«'<"iv e auinonza 

Figure 4 is a block diagram of a connection between a source object, a delegate object, and a sink 
object. The connection illustrated in Figure 4 comprises three objects: a connection point object 40 a 

obtct 4 6 01 r T ^ 3 f* 0bi8Ct 4 ° 3 - del69ate 0bj6Ct 402 IS ™ ed to *° -nn Sn poin 
object «1 through a particular notification interface 404. This same notification interface is used to connec 

the s,n object 403 to the delegate object 402. Thus, the two notification interfaces 404 and 405 are 
different implementations of the same interface definition and thus have the same interface ID 

A typical appl.cat.on of the present invention involves connecting objects in a visual orooramminr. 
environment. Visual programming is a computer programming technique that allows for rap" deve opZ 
o usual y or.ented programs (visual programs,. A visual programming environment typically includes a lis. 
of pre* fined components (objects) that can be interconnected to create a visual program. Each componen 
may include inpu and output ports and a visual interface. When creating a visual program a visua 
s7ecZ m l S T eS th r iS r' C ° mPOnentS th6ir ' OCati0n ° n the diS ^ The visu a r P rogramme so 

Sr^^rs^. 6 ^ various ports - The visuai components th - ~ *- ™* - 

For example, a dialog box for an application program can be created using a visual programming 

oZSTi T7 15 3 ^ di39ram °' 3 ViSUa ' Pr ° 9ramm in9 envir ~ A*Y used to creTtT an 
file nzlT 9 ,° X t T, ^ aPP ' iCati0n Pr ° 9fam - An ° P6n f " e dia ' 09 box is used for rolling through a list of 
file names to select files to open. The visual programming environment display comprises two parts' a 

TZZ n P \T 7" ^ 3 C ° mmand af9a 5 ° 2 - The WOrkspace ^ «• shows S, 
objects be.ng created and connected to program a dialog box visually. The objects currently shown in the 
workspace d.sptay area 50, include an open file dialog box object 503 and four code object 504 507 E h 

T^JZfSTT . SUb ° bieCtS - F ° r eXamp,e - ,he ° pen ,i,e dialo 9 bc * object SOS comprises a 

Me bar object 508 a mult.ple selection list box object 509, and a button object 510. In the state shown the 

obt ? Z7n 2 olt 5°11 ° bi r 18 CUrren, ' y Se,6Cted bV the US6r ,0r Creati " 9 co ™^ ^ 
objects An input port 511 and an output port 512 corresponding to the selected object 509 are shown as 

viSal 9 ! ° b,eC,S h USin9 the various «~ d * Prided by the buttons in the command area 5 02 
v.sual programmer has connected the output port 516 of the open file dialog box object 503 the input and 

anTs \T5 '*! I T 5 k °I t e n mMPie Sel9C,i0n ' iSt b ° X 0bj6Ct «* and ^ ! « ' ouCS 3 
and 514 of the button object 510 to code objects 504-506. Specifically, the output port 516 of the open file 
d.alog box object 503 has been connected to the input port 517 of the code object 504 which con^ns 
code for updating the list of files shown in the multiple selection list box object 509 Also^hetput port 51 ? 

sirzir T n iist box . ° bject 509 has been c ° nnected ,o *• «*« port 518 0 rj co d rob,' c 

selector, list box object 509 is updated to reflect additions or deletions of files since the dialog box was last 

poS of tne'cSe STJn? ? "* *»* 509 ^nn^dTo ^e np 

port 519 of the code object 505 wh.ch contains code for tracking the files selected in the multiple selection 
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list box object 509. This output port has also been connected to the input port 517 of the code object 504 
so that the file list displayed in the multiple selection list box is updated each time the user selects a file. 
The input port 513 of the button object 510 has been connected to the output port 520 of the code object 
505 so that the list of selected files is passed to the button object 510 each time a file is selected. The 

5 output port 514 of the button object 510 has been connected to the input port 521 of the code object 506, 
which contains code that opens each file in the fist of selected files once the user has pressed the OK 
button implemented by button object 510. 

Once created using this visual programming environment, the open file dialog box operates by 
responding to particular system events, for example, events raised from, user input devices. For example, 

w when the user selects the open file dialog box 503, a Mouse LeftButton Down selection event is sent to the 
open file dialog box object 503. Upon receiving this selection event, the open file dialog box object 503 
forwards the notification to the code object 504, because the input port 517 of the code object 504 has 
been previously connected to the output port 516 of the open file dialog box object 503. The code object 
504, which implements code for updating the list of displayed files, then sends an updated file list to the 

is multiple selection list box object 509, because the output port 518 of the code object 504 has been 
previously connected to the input port 51 1 of the multiple selection list box object 509. Also, when a user 
selects a file in the list box implemented by the multiple selection list box object 509 using a mouse input 
device, a Mouse Left Button Down selection event is sent to the multiple selection list box object 509. This 
event is then forwarded to the code object 505 to keep track of the user selection because the input port 

20 519 of the code object 505 has been previously connected to the output port 512 of the multiple selection 
list box object 509. The code object 505 then sends a list of selected files to the button object 510, because 
the output port 520 of the code object 505 has been previously connected to the input port 513 of the 
button object 510. In addition, when a user selects the OK button implemented by the button object 510, a 
system selection event {for example, a MouseLeftButtonDown selection event) is sent to the button object 

25 510. The button object 510 then forwards its output (which in this case is the list of selected files) to the 
code object 506, because the output port 514 of the button object 510 has been previously connected to 
the input port 521 of the code object 506. Upon receiving this button selection event, the code object 506 
opens the files selected by the user. 

In one example application, the present invention can be used to dynamically generate the object 

30 connections needed by the visual programming example illustrated in Figure 5. Figure 6 is a block diagram 
of object connections and data structures after connecting the objects shown in Figure 5 using the present 
invention. Figure 6 shows four objects: a source object 601. which corresponds to the open file dialog box 
object 503 in Figure 5 and three sink objects 602-604, which correspond to the code objects 504-506 in 
Figure 5. The source object 601 , corresponding to the open file dialog box object 503. contains subobjects 

35 corresponding to the title bar object 508, the multiple selection list box object 509, and the button object 
510. (None of the subobjects are shown.) Alternatively, using the present invention, one could create a 
source object for each of the subobjects contained in the open file dialog box object 503 and then connect 
each of the source objects with the appropriate code object (sink object). 

Because the open file dialog box object 503 deals with system events corresponding to the selection of 

40 the open file dialog box object 503, the selection of files within the multiple selection list box object 509, 
and user selection of the OK button implemented by the button object 510, the source object 601 supports 
connection point objects associated with different event sets. Specifically, the source object 601 contains a 
connection point container object 605 and three connection point objects 608, 612, and 615. Connection 
point object 608 is associated with the IMultipleList interface used to support the multiple selection list box 

45 object 509. Connection point object 612 is associated with the IButton interface used to support the button 
object 510. Connection point object 615 is associated with the IDialog interface used to support the open 
file dialog box object 503. The connection point container object 605 provides the IConnectionPointCon- 
tainer interface and maintains a list of pointers to connection point objects. In Figure 6, the list of pointers to 
connection point objects currently has three elements 606. 607, and 618. Each element contains an 

so indicator of the interface ID associated with the connection point object, a pointer to the IConnectionPoint 
interface of the connection point object, and a pointer to the next element of the list. One skilled in the art 
would realize that other data structures could be used to manage the set of created connection point 
objects. Also, more or less information could be associated with each list element for efficiency reasons. 
For example, each element need not store the interface ID, as the interface ID is readily accessible from the 

55 connection point object. 

Each connection point object provides the IConnectionPoint interface and maintains a list of references 
to notification interfaces belonging to sink objects. A reference to a notification interface of a sink object is 
added to this list whenever the sink object requests a connection from a connection point object using the 
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Connect.onPo.nt interface. The connection point object 608. which is referenced by the list element 606 in 
the connection point container object 605, currently shows a list of references to notification interfaces 
containing two elements 610 and 6,1. A header for the list of references to notification interfaces 609 i 
provided for quick access to the associated interface identifier and to the first list element. Each list element 
contains a token uniquely identifying the connection, a pointer to the (Unknown interface of the connected 
sink object and a pointer to the next element in the list. For example, list element 610 contains a token 
uniquely identifying the connection with sink object 602, which corresponds to the code object 504 for 
updating the list of files displayed by the multiple selection list box object 509. List element 610 also 
r a n^f> a P t 0in,er . t °J he i ,U ? kn0VVn ' nterfaCe ° f Sink ° bjeCt 602 in order 10 access the 'MultipleList interface 
X Tl TJ\ T °' S ' nk ° bjeCt 6 ° 2 - USt el6ment 610 alS0 provides a e° in *rlo list element 6,1. 

tilw 1 9 V C ° nneCtS t0 Sink ° bjeCt 603 ' which corresponds to code object 505 for 

keeping track of the selected files. 

nh . ? n " e , C,i0 'I P f ^ ° bieCt 612 implemen,s the connection between the button object 510 and the sink 
object 604. wh.ch corresponds to the code object 506 for opening files selected by the user In an 
ri° 90 * U «i7T t0 C ° nnection point ob ' ect 608 - connection point object 612 contains a list with one 
element 614. Element 614 contains a pointer to the (Unknown interface of sink object 604 which 
corresponds to code object 506. In addition, connection point object 615 is analogously connected to a 
notify , on interface of sink object 602. Note that the notification interface of sink object 602 that is 

IT^ZVV^TrTZ P ° im ° bieCt 615 ( ' Dial09) iS different ,rom the noti,ication in ^e of the same 
sink object ( IMult.pleL.st) that ,s connected to connection point object 608. However, in this embodiment 

both connection pent objects 608 and 615 contain a pointer to the lUnknown interface of sink object 60 2 ' 

As shown ,n Figure 6. a connection point object can be connected to more than one notification interface (of 

one or more s.nk objects) and a sink object can be connected to one or more connection point objects 

fife ^innT 9 , J?T 6 ' Wh6n S0Ur ° e ° bieCt 601 r8CeiveS the event associated with se ^ting the open 
1^,^ ?h S ° UrCe ° bieCt 601 Wi " fiPd ,he C ° nneCti0n P0int <**** corresponding to the (Dialog 
interface (615) The source object 601 will then notify the sink object 602. which updates the list of files 

aTori^V !° 9 T. V Slnk ° bjeCt 6 ° 2 - WhGn the S ° UrCe 0bi6Ct 601 receives a selec tion event 
associated with selecting the multiple selection list box object 509, the source object 601 will find the 

finrS^nf nt Obi * ctcorrespondir1 9 t0 ^ "MultipleList interface (608), and then will notify sink objects 
Sf 1,1 USm ? ^ C ° nneC,ed noti,ication interfac es (IMultipleList). Likewise, when the source object 
60 winTnH ,h S 6Vent aSS0Ci3ted With ,h6 US6r preSSing ,he button object 510. the source ob ect 

sink llltVnl C ° nne !; P °' nt ° bjeCt correspondin 9 10 th * 'Button interface (612), and then will notify 
sink object 604 usmg the connected notification interface ((Button). An example of the event notification 
corresponding to selecting the burton object 510 is discussed with reference to Figure 9 not,f,catl0f1 



Code Table t 

interface IConnectionPoint: public lUnknown { 

virtual HRESULT GetConnectionlnterface (REFIID piid) = 0; 
virtual HRESULT GetConnectionPointContainer (IConnectionPointContainer 
**ppCPC) = 0; 

virtual HRESULT Advise (lUnknown 'punk. DWORD 'pdwToken) = 0- 

virtual HRESULT Unadvise (DWORD dwToken) = 0; 

virtual HRESULT EnumConnections (lEnumConnections 4 *ppEnum) = 0; 
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interface lEnumConnections: public [Unknown { 

virtual HRESULT Next (ULONG cConnections, CONTNECTDATA Vgpunk, 

ULONG •lpcFetched) = 0; 
virtual HRESULT Skip (ULONG cConnections) « 0: 
virtual HRESULT Reset ( ) = 0; 

virtual HRESULT Clone (lEnumConnection ••ppEnum) = 0; 



struct tagCONNECTDATA { 
70 [Unknown *punk; 

DWORD dwToken; 
} CONNECTDATA; 

;s Code Table 3 contains C+ + pseudocode for a preferred definition of the interfaces IConnectionPoint 
and lEnumConnections and the data structure returned by the enumerator interface lEnumConnections. The 
IConnectionPoint interface contains methods for connecting and disconnecting to the connection point 
object and for enumerating the notification interfaces connected to the connection point object. The method 
GetConnection Interface returns a pointer to the interface ID associated with the connection point object. The 

20 method GetConnection PointContainer returns a pointer to the IConnectionPointContainer interface of the 
connection point container object containing the connection point object (its parent container object). When 
the connection point object is instantiated, the creation method of the connection point object is passed a 
pointer to the connection point container object for future use. The method Advise connects the notification 
interface specified by the parameter punk to the connection point object and, if successful, returns a unique 

25 token identifying the connection in parameter pdwToken. The unique token may be stored persistently. The 
method Unadvise disconnects the notification interface specified by the input parameter dwToken. The 
method EnumConnections returns an enumerator interface, an instance of the interface lEnumConnections, 
for iteration through the connected notification interfaces. 

The interface lEnumConnections implements the enumerator used by the IConnectionPoint interface. 

30 This enumerator contains a set of methods for enumerating the notification interface connections for a 
particular connection point object. The two methods of interest include the method Reset, which reinitializes 
the enumerator to point to the first connected notification interface and the method Next, which returns a 
pointer to the next connected notification interface. Code Table 3 shows a typical structure definition for the 
connection information returned by the enumerator method Next referred to as CONNECTDATA. 

35 

Code Table 4 

interface IConnectionPointContainer public (Unknown { 
40 virtual HRESULT EnumConnectionPoints (lEnumConnectionPoints **ppEnum) = 0; 

virtual HRESULT FindConnectionPoint (REFIID iid. IConnectionPoint **ppPoint) = 0; 

i 

interface [EnumConnectionPoints: public lUnknown { 
45 virtual HRESULT Next (ULONG cConnections. IConnectionPoint *rgpcn. 

ULONG •|pcFetched) = 0; 
virtual HRESULT Skip (ULONG cConnections) = 0; 
virtual HRESULT Reset ( ) = 0: 

virtual HRESULT Clone (lEnumEmbeddedConnection **ppecn) = 0; 

50 } 

Code Table 4 contains C+ + pseudocode for preferred definitions of the interfaces IConnectionPoin- 
tContainer and lEnumConnectionPoints. The IConnectionPointContainer interface implements methods for 
55 finding a particular connection point object and for enumerating the set of contained connection point 
objects. The lEnumConnectionPoints interface implements the enumerator method used by the IConnec- 
tionPointContainer interface. The IConnectionPointContainer interface contains a method FindConnection- 
Point which returns a pointer to an IConnectionPoint interface given a specified interface ID. The method 
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IEnumConnect.onPo.nts returns a pointer to the interface lEnumConnectionPoints for iteration through the 
coined set of connection point objects. The interface lEnumConnectionPoints caJ^ ?ZJ!£^ 
for .nu.al.ang the enumerator to point to the first connection object and a method Next foT reWevina a 
pointer to the IConnectionPoint interface associated with the next connection oc!nt Set tored T 'he 
5 connection point container object. 

Corresponding to the example discussed with reference to Figures 5 and 6. an object comprising the 
visual programme env.ronment depicted in Figure 5 acts as an initiator object to set up connect on 

0 Tnd 0 6 T fi '% dial09 0bi6Ct 503 (thG S ° UrCe ° bieCt) ^ the Code Uect, sTnK ob ec, 5^ 
,n nhtr, Tl ,S 3 "° W dia9ram °' 3 ' unction SetUpConnection for connecting a specified sink 

mollntinaThe 'f T™* ^ 3 n0tifiCati0n intert *»- The objeS (.hfcode 

implementing the vsual programm.ng environment) could use this function to set up all of the connections 
s own m figure. 5 and 6. The function SetUpConnection provides one examp.e of using LTn ZTel 

hZan ?T 3 4 10 S6t UP an eVen ' handNn9 SCheme - 0ne ski,led in *• art would recogn^e 

that many uses of these interfaces and different functions than SetUpConnection are possibie 

The function SetUpConnection determines the connection point object on the source object for 

connecting and connects the appropriate notification interface of the sink object to the connection po n 

object. The function takes three input parameters: pSrc. which is a pointer to some ,^ 30^ 

S Tntl C ° nne . \f WhiCh iS 3 P ° inter ,0 S ° me interface of the sink to connect and iid wn*h * 
the interface .dentif.er associated with the connection point object to which the sink object desTes to 

SI?: ,UnCti0n ? I,S m6th0d interface of the specified source^c Z a te 
the IConnectionPointContainer interface of the specified source object. In step 702 the function uses the 
returned IConnectionPointContainer interface pointer to invoke the method RndLrJii^rS^ 

to Rgure 8.) In step 703, the function saves the returned pointer to the connection point object for use at 
aZ^lc*:; »h°: Th diSC ° nneC,in 9 *. sink object. In step 704, the function el's he method 
Querylnterface of the specified s.nk object to obtain a pointer to the lUnknown interface of the sink obiect 
In step 705, he function calls the method Advise of the connection point object (returned in s ep 702) to 
connect the lUnknown interface of the sink object to the connection point ob ect rZ^LZlesZ 
pointer to the .Unknown interface of the sink object in the call to Advise, and if sue sfT the method 
Adv.se returns the token uniquely identifying the connected notification interface. In ste 706 Tme 
connect.cn was successfu.lv performed by the method Advise, the function continues in step 707 e se 
re urns an error. In step 707, the function saves the token returned by the method Advise TlJeruse n 
disconnecting the notification interface of the sink object, and then returns 

ortr rt Th ^?^ S ,T ( ^T t 5 n inCOrporates one wa V of ^tting up connections between connection 
po,nt objects and sink objects. One skilled in the art would realize that there are many alternatives For 

SST"," >T 10 St6P 702 US6S ^ 6nUmerat0r meth0d Enum ConnectionPoints of Te SZeJoZ 
" Ce 10 dete ™ e the action point object. Also, if a sink or initiator ob£ "ready 

the LC r J " C0 " ne o t,0n r int 0bi8Ct in the source <***■ the " the sink or initiator object can use 
rLJ? Ge Co"nect.onPo,ntContainer of the IConnectionPoint interface to retrieve a pointer to the 
connection po.nt container object to search for a different connection point object. Also if a sink or initial 

memod ah V h 3S ° b , tained ^ d6Sired C0nn9C,i0n POint 0biect ' then ,he sink or initiator b e can a the 
method Adv,se d-rectly. c.rcumventing the preliminary steps. In addition, a preferred embodiment assumed 

l^rT 6 ' Unkn0Wn interf3Ce ° f * he Specified sink ob * ct is the interface pointer stored inTe 

specified connects po.nt object. The .Unknown interface is used to support the persistent sToraoe ol 
connection pent objects and enable delayed binding to a connected sink or delegate obfrt lZlZw 

Z Z : Tl^T f !?T n °H iCa,i0n interf3Ce itS6lf ' With ° Ut — *» ^Ced bfndlg' a rno e 
that ,n th,s function and those d.scussed below, reference counting has been omitted to simoNfv 
explanation. One skil.ed in the art would recognize that as object connections are created 2d IsZe? 
reference counts are preferab.y updated and that cyclical references are preferably avoided 

int^r™ 13 M'T di39ram f ° r th6 m6,h0d IConnectionPoint of the IConnectionPointContainer 
interface. This method returns a pointer to an IConnectionPoint interface of a connection pom obiec 
corresponding to a specified interface identifier. The specified interface identifier is passed as an Sou 

c 0 n?«rHn^l?Sf ' L . "* 0< ins,an «ated connection point objects looking for the 

connect-on po.nt object corresponding to the specified interface identifier. In steps 807-Sto if fcZ^d 
,ng connection point object has not been found, then the method instantiates a L connec ioS point oWect 

r or 9 ::Z^7^ t T r,W ^ SUPP0rt6d bV ** S ° UrCe 0bj6Ct: ° therwiS9 ' SmZSZ 
error. In step 80t. a temporary vanable ,s set to point to the IConnectionPoint interface pointer contained in 
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the first list element. In step 802. the method GetConnection Interface of the interface pointed to by the 
temporary variable is invoked to determine whether the interface ID associated with the connection point 
object referenced by the temporary variable (the current connection point object) matches the specified 
interface ID- In step 803. if the returned interface ID matches the specified interface ID, then the method 

5 continues at step 804, else continues at step 805. In step 804, the method sets the output parameter to 
point to the address of the IConnectionPoint interface pointer referenced by the temporary variable, and 
returns. In step 805. the temporary variable (which points to the current connection point object) is set to 
point to the IConnectionPoint interface of the next element in the list of instantiated connection point 
objects. In step 806. if the method has reached the end of the list, then the method continues at step 807. 

w else the method returns to the beginning of the loop in step 801. In step 807, the method determines 
whether the specified interface ID corresponds to a connection interface that the source object supports, 
and if so. the method continues at step 808, else returns in error. In step 808, the method instantiates a new 
connection point object. In step 809, the method inserts the newly instantiated connection point object into 
the connection point container object's list of connection point objects. In step 810. the method sets the 

/ 5 output parameter to point to the address of the newly instantiated connection point object, and returns. 

The steps comprising the method FindConnectionPoint in Figure 8 assume that connection point 
objects are instantiated dynamically as needed. One skilled in the art would recognize that connection point 
objects can be established dynamically or statically at the discretion of the source object implementation. 
For example, upon instantiation of the source object, a connection point object corresponding to each 

20 connection interface identifier supported by the source object could be instantiated with empty lists of 
references to notification interfaces. Also, certain steps could be eliminated for efficiency reasons from the 
method FindConnectionPoint if the connection point container object is implemented with knowledge of the 
connection point object implementation structure. Such knowledge might typically occur if the source object 
implementation provides its own implementations for the connection point container object and the 

25 connection point objects. In addition, the method FindConnectionPoint assumes that the data structure used 
to store references to the connection point objects is a list structure as shown in Figure 6. This method 
could be alternatively written to handle various storage data structures. 

Figure 9 is a flow diagram of a method that uses an established connection between a source object 
and a sink object. Specifically, Figure 9 illustrates a set of steps that could be performed by the source 

30 object corresponding to the open file dialog box object 503 in Figure 5 when the source object receives a 
system selection event indicating that a user has depressed the OK button object 510. This example 
assumes the connections have been appropriately established as discussed with reference to Figure 6. One 
skilled in the art would recognize that many other uses of and semantics for the object connection 
mechanism are possible. 

35 When a user depresses the OK button object 510 in Figure 5, the system sends a selection event to 
the source object. The source object then invokes some internal routine to respond to the externally raised 
event. Figure 5 depicts an example of such a routine, which is the method OK__ButtonDown for the 
IDialogBox interface. The OK_ButtonDown method determines which connection point object corresponds 
to the interface identifier associated with the raised event and invokes a predetermined method of the 

40 notification interfaces connected to the determined connection point object. As described earlier, because 
the set of events that includes the raised event is represented by an interface, the source object has 
knowledge of what methods are supported by a connected sink object. Furthermore, in the source object 
routine handling the raised event (in this case, the OK_ButtonDown method), the source object can 
determine which particular method of the sink object it prefers to invoke to handle the raised event, tn this 

45 particular example, the method determines that the method Mouse Left Button Down of the notification 
interface corresponding to the interface identifier IID_IButton is preferably invoked to respond to the raised 
selection event. 

In step 901, the method obtains its own IConnectionPointContainer interface using the method 
Querylnterface. In step 902, the method uses the IConnectionPointContainer interface pointer to invoke the 

so method Find Connection Point requesting the connection point object that corresponds to the interface 
identifier IID_IButton. In step 903, the method invokes the method Enum Connections of the connection 
point object returned in the previous step to obtain an enumerator for enumerating the contents of the 
connection point object. In step 904, the method resets the enumerator to start at the beginning of the list of 
references to notification interfaces. In step 905, the method invokes the method Next of the enumerator to 

55 obtain the connection data for the next referenced notification interface. In step 906, if the enumerator 
indicates no more references to notification interfaces are present, then the method returns, else the 
method continues in step 907. In step 907. the method calls the method Querylnterface of the lUnknown 
interface indicated in the connection point data structure requesting the notification interface corresponding 
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° I 'Z , T IID -' But, ° n ' US ' ng 3 rem ° te Pr0cedure ca " if necessar V- A <*™* P^edure call 
1 1 necessary rf he connected notification interface belongs to an object contained within another process 
address space. In step 908, the method invokes the method MouseLeftButtonDown of the retrieved Button 

T n" 19 luT* h^ 006 ^ 6 Ca " " neCeSSary) " 3nd COntinues back ,0 the be 9 if1 ™9 of the loop in 
step 905. One stalled in the art would recognize that multiple steps of this method could be eliminated for 
efficiency reasons if the implementations of the connection point container object and the connection point 
obiects are known by the source object implementation. 

inJ^TrH 1 3 !'° W K ia9fam ° f 3 ' UnCti0n d6fined by a sink obiect 10 disconnect a specified notification 
interface. The function has one input parameter, which is the interface ID of the notification interface the 

""If 160 f ,res 10 disc °™ect. 'n step 1001, the function retrieves the pointer to the IConnectionPoint 
nterface of he connection point object for the specified interface ID, which was previously stored during the 
funcbon SetUpConnection (see step 703 of Figure 7). The function also retrieves the token uniquely 
nn? k 6 f meCtion previous| y established for the specified interface ID (see step 707 of Figure 7) In 
step 1002, the function calls. the method Unadvise of the retrieved IConnectionPoint interface, passing it the 

LTnl 1 h T d T mS ;- m6th0d Un3dViSe ° f ,he lc °™ctionPoint nterface uses the specified 
7 T * tS "? ° f referenCeS t0 n ° ,ifiCati0n interfaces ,0 find the corresponding notation 
interface reference. The method Unadvise then removes the references to the corresponding notification 
interface from the list of connected notification interfaces, thus disconnecting the corresponding notification 



Code Tahlg ^ 

interface IProvideCIasslnfo: public Unknown { 

virtual H RESULT GetCIassInfo (ITypelnfo "ppti. CLID Icid) = 0; 

> 

wh>?f Table w 5 h con,ains C+ + Pseudocode for a preferred definition of the interface IProvideCIasslnfo 
wh ch can used by a sink object to obtain information about an unknown source object. The method 
GetCIassInfo of the IProvideCIasslnfo interface can be used by a sink or initiator object to obtain cZ and 
type information from an unknown source object in order to connect to it. The ITypelnfo interface describes 
the interfaces implemented by the source object, what events its raises, and what properties it supports I 
n erfl H °?? ^ ^ *" in '° rmati ° n * S6 « UP COmpatible connections. The ITypelnfo 
sTs^for mtT .' n t e,a " U S ' Patem ApP ' icati0n Serial No - 07/959.058. entitled "Method and 
System for Interfacmg to a Type Library." which is hereby incorporated by reference 

in JH^T at ^ Pre T IT" 0 " h3S b6en d6SCribed in terms °* a P referred embodiment, it is not 
bTanSrinf TH * embodim8nt Modifications within the spirit of the invention will 

Sow ,n 3rt - SC ° Pe ° f thS PreS6nt inV6nti0n iS defined b * the claims which 

Claims 

1 * n hi l e f th0d H in aC ° mputer Sy u Stem ,or dynamically generating an object connection between a source 
source ohtrVli f )eCt k 6 ''"I! ° bieCt haVin9 3 n ° tifiCati0n interface for communicating with the 

IthnH T°* ° bJ6Ct haVi " 9 C ° nn6Cti0n p0int in,erfaces for connecting a sink object, the 

method comprising the steps of: 

selecting a connection point interface for connecting the source object to the sink object- 

and Z^'J™^ Se,e °,! ed C ° nneCtiCn POint interfaCe ' 3 rec > uest to co "" ec t the source object 
I " h ^.' th ° «* u ° st havi "9 a " i^ication of the notification interface of the sink object; and 
s onng the mdicated notification interface, whereby the source object communicates with the sink 
object using the indicated notification interface. 

2 ' IflT^ °« Cla 'T 1' ' Urther inClUdin9 th9 Step <* under contro1 Qf the source object, invoking the 
stored notification interface of the sink object. 
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3. The method of claim 1, the connection point interface for connecting to a plurality of sink objects, 
wherein the steps of receiving a request to connect and storing the indicated notification interface are 
performed for each sink object, and further including the step of: 

invoking the stored notification interface for each sink object. 

5 

4. The method of claim 1 wherein each connection point interface connects to a plurality of sink objects, 
and wherein the step of selecting a connection point interface chooses a connection point interface 
based upon the notification interface of the sink object. 

w 5. The method of claim 4, the source object having a connection point container object for managing 
interaction with the plurality of connection point interfaces and wherein the step of selecting a 
connection point interface includes the substep of requesting a connection point interface from the 
connection point container object. 

/5 6. The method of claim 1 , the connection point interface having an advise member function for requesting 
a connection to the source object, wherein the step of receiving a request to connect is performed 
under the control of the advise member function of the connection point interface. 

7. The method of claim 1 wherein the step of selecting a connection point interface is performed under 
20 the control of the source object. 

8. The method of claim 1 wherein the step of storing the indicated notification interface is performed 
under the control of the source object. 

25 9. The method of claim 1 , further comprising the step of, under control of the sink object, requesting a 
connection. 

10. The method of claim 9, the computer system having an initiator object for setting up connections 
between a source object and a sink object, wherein the step of requesting a connection is performed 

30 by the initiator object. 

11. A method in a computer system for registering .a notification interface of a sink object with a source 
object, the source object having a function member for registering the notification interface of the sink 
object, the notification interface for communicating with the sink object from the source object, the sink 

35 object having a plurality of notification interfaces, the method including the steps of: 

selecting a notification interface from the plurality of notification interfaces to register; and 
requesting registration of the selected notification interface using the function member of the 
source object. 

40 12. The method of claim 11, the source object having an advise member function for requesting 
registration of a notification interface, and wherein the step of requesting registration invokes the advise 
member function of the source object to make the request. 

13. The method of claim 11, the sink object having an lUnknown interface for accessing other interfaces of 
45 the sink object, and wherein the step of selecting a notification interface chooses the lUnknown 

interface of the sink object. 

14. The method of claim 9, the computer system having an initiator object for registering a notification 
interface of a sink object, wherein ail steps are performed by the initiator object. 

50 

15. A method in a computer system for dynamically generating an object connection between a source 
object and a sink object, the sink object having a plurality of notification interfaces for communicating 
with the sink object, the source object having connection point interfaces for connecting the sink object, 
the method comprising the steps of: 

55 selecting a connection point interface for connecting the source object to the sink object; 

selecting a notification interface from the plurality of notification interfaces; 

using the selected connection point interface to request that the source object and the sink object 
be connected, wherein the request indicates the selected notification interface; and 
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storing the indicated notification interface so that the sink object can be notified by the source 



16. The method of claim 15. further including the step of invoking the stored notification interface. 

17. A computer system for dynamically connecting objects, the system comprising- 

nn 3 ,?r" ,y ? T 0bieC,S ' 8aCh $ink ° bi6Ct having 3 n °««cation function member for communicat- 
ing with the sink object from the source object; and cummunrcai 

nntifL^n °! S ° UfCe l b ' eCtS ' e3Ch S ° UrCe ° bieCt having 3 P ' Ura,it V of connection points for storing a 
no.if cat.on function member of a sink object, each connection point storing a plurality of notification 
unct,on mem ers and returning an identification o, a notification function member fror/the p u a 0 

stored notification function members upon request. 

18 " ITJJJT ° f ? aim J. 7i C ° mPriSin9 3 C ° nneCti0n p0int container for ^nng the plurality of 

dZm np h°h " S ° UrCe ° bjeCt ' the C ° nneCti0n P0int contai ™ laviSg the ability to 

determ.ne which connection point to use when an object connection is requested. 

19. The system of claim 17, further comprising an invocation mechanism used by a connection point to 
tnvoke a stored notification function member. P 
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© A method and system for dynamically generat- 
ing object connections is provided. In a preferred 
embodiment, a connection can be generated be- 
tween a source object and a sink object using a 
connection point object. A source object has connec- 
tion point objects where each connection point ob- 
ject corresponds to a particular interface. A sink 
object implements one or more notification interfaces 
for connecting to. a source object. A connection point 
object of a source object can connect to multiple 
notification interfaces, which belong to one or more 
sink objects. A connection point object keeps track 
of pointers to the notification interfaces to which it 
has been connected. In order to generate a connec- 
tion, a sink object requests from a source object a 
connection point object corresponding to a particular 
interface. The source object determines whether it 
supports such a connection point object, and if so 
returns a pointer to the connection point interface of 
the determined connection point object. The sink 
object then requests to be connected to the connec- 
tion point object using the returned connection point 
interface pointer and passes a reference to a no- 
tification interface of the sink object corresponding to 
the particular interface. The connection point object 



then stores the reference to the notification interface 
of the sink object, creating a connection between the 
sink object and the source object. At some later 
time, the source object can utilize the connection to 
notify the sink object through the connected notifica- 
tion interfaces. 
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